The core information technology (IT) systems for many businesses have been in service for many years—even decades. These systems were developed on and optimized for legacy platforms, and are difficult to link to new technologies such as Web services and service-oriented architecture (SOA). The convergence of SOA and mainframe technologies can help enterprises liberate these core business assets by making it easier to enrich, modernize, extend and reuse them well beyond their original scope of design.
A web service can be generally defined as one or more application functions that can be invoked over the Internet using a protocol. One example of a protocol that may be used in this context is the Simple Object Access Protocol (SOAP), which may be used by Internet-based application servers or web servers, to provide web services. SOAP is a protocol that is often used in the exchange of information in decentralized, distributed network environments. Typically, web services are self-contained and self-describing. For example, a web service may be a reusable application component that offers operations, such as currency conversion, weather reports or language translation. These components may be used by applications, which pass requests to the web service to perform its particular operation(s). Web services may also be used to exchange data between different applications and different platforms.
A service registry and repository is an application that manages service descriptions as data objects in a relational database system. Service descriptions are used by analysts, architects, and developers during the development phase of the SOA life cycle to locate services to reuse and to evaluate the impact of changes to service configurations. Typically a user uses a graphical tool to design classes that represent the service descriptions that need to be managed or maintained. For example, Java objects that represent the classes are compiled into binary files. A database schema is generated that can represent the objects and is installed into a relational database. The service registry and repository registers and stores service descriptions as part of a SOA promising business agility and resilience through reuse, interoperability, integration and governance. These promises are addressed by separating service descriptions from their implementations, and using the service descriptions across the life cycle of the service. Standards-based service metadata artifacts, such as Web Service Definition Language (WSDL), XML schema, policy or Service Component Architecture (SCA) documents, capture the technical details of what a service can do, how it can be invoked, or what it expects other services to do. Semantic annotations and other metadata can be associated with these artifacts to offer insight to potential users of the service on how and when it can be used, and what purposes it serves.
WSDL is a language based on extensible Markup Language (XML) that is used to describe how to communicate with web services. WSDL defines services as collections of network endpoints, or ports. A WSDL document is an XML document that describes a web service, including the web service ports and messages. A port is defined by associating a network address with a reusable binding, and a collection of ports define a service. Messages are abstract descriptions of the data being exchanged, and port types are abstract collections of supported operations. The concrete protocol and data format specifications for a particular port type constitutes a reusable binding, where the messages and operations are then bound to a concrete network protocol and message format. In this way, WSDL describes the public interface to the web service.
WSDL is typically used in combination with SOAP (Service Oriented Architecture Protocol) and XML schema to provide web services. A client program connecting to a web service can read the web service's WSDL file to determine what functions are available. Any special data types are embedded in the WSDL file in the form of XML schema. The client can then use SOAP to actually call one of the functions listed in the WSDL file.
With an SOA, an inventory of structured, loosely coupled services that perform a single function can be choreographed to build business processes—yet the underlying implementation is isolated from the consumer. The user of the service is only aware of the function being performed, not of the details of how the function is implemented. With this service model in place, IT can rapidly add new functions and modify existing processes by simply assembling the services required to meet the new or enhanced business process model.
Furthermore, different applications from different sources can communicate with each other without extensive custom coding, and web services are not associated with any one operating system or programming languages. This flexibility allows more sophisticated business-to-business applications as well as more sophisticated browsing models (with more client-side processing of data) to be developed.
While the business benefits of SOA are clear—increased business flexibility, faster application development turnaround time and economical code reuse—SOA creates more moving parts for IT organizations to keep track of, monitor and govern. That implication affects both developers and production personnel. Managing a few services with limited exploitation is usually no problem; however, managing tens or hundreds of services through application lifecycles across production systems requires significant organization. SOA-based applications can call services through an enterprise service bus (ESB), which can dynamically choose services based on specific needs, operational characteristics and service level agreements. In turn, services can call other services and applications may follow a different path each time they run. As a result, the ability to stay on top of the details can quickly become very difficult unless there are effective organizational tools.
The requirement that all external identifiers in XML documents must provide a system identifier has unquestionably been of tremendous short-term benefit to the XML community. It has allowed a whole generation of tools to be developed without the added complexity of explicit entity management. However, the interoperability of XML documents has been impeded in several ways by the lack of entity management facilities. External identifiers may require resources that are not always available. For example, a system identifier that points to a resource on another machine may be inaccessible if a network connection is not available. External identifiers may require protocols that are not accessible to all of the vendors' tools on a single computer system.
WSDL is an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information. The operations and messages are described abstractly, and then bound to a concrete network protocol and message format to define an endpoint. Related concrete endpoints are combined into abstract endpoints (services). WSDL is extensible to allow description of endpoints and their messages regardless of what message formats or network protocols are used to communicate. If a direct association between an XML file and an XML schema or DTD file is created, then for any change to the location of the schema or DTD, all of the referencing XML files must be tracked down and updated with the new location of the DTD or schema. XML documents typically refer to external entities. These external relationships are expressed using URIs, typically as URLs. However, if they are absolute URLs, they only work when the network can be reached. Relying on remote resources makes XML processing susceptible to both planned and unplanned network downtime. Conversely, if they are relative URLs, they are only useful in the context where they were initially created. The XML catalog is a document describing a mapping between external entity references and locally-cached equivalents.
There especially exists a challenging problem regarding how to govern documents such as WSDL and XSD documents yet make them accessible to development and other tools. Some schemas, such as that for XML itself, are defined to be available at an absolute address on the Internet. For example, in the case of the schema for XML, it is available at http://www.w3.org/2001/xml.xsd. There are several potential problems with always accessing a schema with an absolute address on the Internet. One is that the network connection or the server may be unavailable. Another is that the file may be replaced with a newer version and this could break any existing files that reference the file that was changed.
To avoid these issues, current techniques include requiring developers/users to download copies of such files to their local computer but this requires that users downloading a copy have to either change their own files to refer to the downloaded file in its local location or they have to manually map the original reference to a reference to the local copy. This approach also has the problem that if the original file is updated then everybody that has downloaded their own copy has to download the new copy.